This application is directed to implementing domain data configuration changes, additions, and deletions during the run-time operations of a software system.
Data is critical to virtually all information systems, and the accuracy, completeness, and availability of data is a distinct measure of an information system's value. Complex information systems, such as those supporting thousands of transactions, queries, and user interactions per hour, typically include one or more databases responsible for maintaining and managing the vast amounts of operational and archival data. Transient operational data is particularly sensitive to the disruption of run-time operations and, if the system is vital, often requires highly specialized measures to protect it (e.g., fail-over, redundancy, and hot-standbys for sustained operation, recovery, and prevention of data loss). Among the transient data in use, statically figured data normally defines the fixed domain environment or context within which the system operates, while dynamic data exists temporarily to facilitate operations and act as a vehicle for persisting event data. In some industries and public sector applications, the information systems in use do not require changes to the definition of their static domain environment data very often. In other businesses and government systems, however, the need to make such changes is both frequent and ongoing. Such an information system may require monthly, weekly, or even daily modifications to its statically configured domain data. Depending on system design and the extent of reconfiguration, implementing changes typically requires taking the software system off-line, either in full or in part, recompiling the software with the new configuration data, and bringing the system back online. For many businesses and government operations, this is not only a tremendous inconvenience; it is a costly and precarious procedure.
Routinely, in the course of maintaining a large, sophisticated information system, the need arises to reconfigure aspects of the domain environment that defines the system. Domain data can be considered both the arena within which the system operates and the static, semi-permanent constructs that serve as vehicles, parameters, and mechanisms for carrying out business operations through the system. Much of this static domain data represents actual, physical devices that are themselves subject to reconfiguration, replacement, and inclusion in the system. In general, a change to domain data is either driven by (1) changes to the physical environment emulated by the software, or (2) by a decision to reconfigure the definition of domain data to optimize, correct, or simply the role of these static elements in the information system. Once a change is decided upon, the development of the reconfiguration “change set” is invariably performed offline, usually by a back office system administrator, software engineer, or database personnel. Developing the “change set” offline has many advantages. It offers the opportunity to create the new configuration independent of the various technical and business constraints imposed by an operational environment, allows for desk-checking, automated testing, and database validation. Once ready for incorporation, the offline developer needs to make the change set available to the information system. Most prior art data reconfiguration methods produce an entirely new baseline database to be manually uploaded into the system at a time when the system can be taken down with relatively little impact on operations.
The loss of revenue due to “downtime”, or worse yet the potential for human casualty, can make database changes (or upgrades) a harrowing ordeal for the maintainer of the system. Dispatching and control systems are particularly vulnerable to the adverse effects of downtime. Whether the system is responsible for controlling aircraft, trains, military drones, or satellites, the need to maintain continuous operation is essential. It is also imperative to minimize the affected area of the system and to constrain the disruption to the fewest functions possible. Clearly, a means of maintaining a high level of system availability while reconfiguring a system's static domain data during run-time is the ideal, but it can be as technologically challenging as changing the carpet out from under the feet of guests at a cocktail party. The difficulty lies in the established dependencies among transient data, the complex interactions among software objects, and the ability of the software to recognize and incorporate not only changes, but additions and deletions, as well, without adversely impacting or corrupting the system.
The present disclosure addresses the problems identified in the prior art by allowing reconfiguration of domain data to the run-time system without requiring the system to be taken down, and to limit reconfiguration to only the affected data.
In another aspect, the present disclosure maximizes the availability of system functions by limiting the reconfiguration to only the affected data. In a further aspect, the present disclosure minimizes the number of affected entities, offers alternative configuration changes from a common baseline, and performs run-time reconfiguration in real time. In another aspect the present application detects dynamic software entities currently using the domain data subject to change and (a) automatically removes from the system those dynamic entities that are non-critical, (b) coordinates the removal of problematic dynamic entities through a user interface, and (c) updates the remaining dynamic entities to reflect data changes.